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LOCAL COMMUNICATION SYSTEM 

A local communication system which combines source 
data (CD audio, MPEG video, telephone audio etc) with 
control commands in a low cost fibre network is available 
in the form of D2B Optical- For details, see for example 
the "Conan Technology Brochure" and the "Conan IC Data 
Sheet" available from Communication & Control Electronics 
Limited, Stirling House, Stirling Road, The Surrey 
Research Park, Guildford, Surrey GU2 5RF- See also 
German patent applications of Becker GmbH with filing 
numbers 19503206.3 (9SP03), 19503207.1 (95P04), 
19503209-8 (95P05), 19503210.1 (95P06), 19503212.8 
(95P07), 19503213.6 (95P08), 19503214,4 (95P09) and 
19503215.2 (95P10). "Conan" is a registered trade mark 
of Communication & Control Electronics Limited. 

The present invention aims to enable expansion of 
the capacity of such a network, for use in vehicles and 
the like, towards a capacity necessary for higher bit- 
rate multimedia applications such as MPEG2 audio, MPEG2 
video, Digital Audio Broadcasting (DAB), Digital 
Versatile Disk (DVD) and other data. 

One proposed embodiment employs asynchronous 
transfer mode data transport for the various data types, 
accommodating both high bit rate and low bit rate data 
channels. However, the ATM packet is not limited to the 
conventional ATM packet of 5 bytes of header and 48 bytes 
^ . , *^ 3 r>foH i-<-> provide more efficient use 

or p c* y J- <-» l-i , k> ^» ^ ^ ^ — sr 

ot oanawiacn in uaiycu ^^^^^^^ 

Also, compared with D2B Optical . (CONAN) technology, 
it is proposed to use a more compact encoding technique 
35 for the fibre interface, such as the 4B5B or 8B10B 
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encoding, currently used in FDDI (Fibre Distributed Data 
Interface) for metropolitan area networks (MANs ) , 

Embodiments are proposed, in which each network 
frame includes subframes of at least two different modes: 
"mode 0" subframes provide compatibility with the fixed 
bit-rate (e.g. circuit-switched) CON AN technology, while 
simultaneously the "mode 1" subframe provides a group of 
bytes which can be allocated more freely to implement a 
variable bit-rate (e.g. packet-switched) channel. In 
other embodiments, a common source data channel is 
allocated dynamically' between circuit-switched and 
packet-switched data. 

These " proposals and surrounding considerations are 
described in the following pages, together with some 
alternatives also proposed herein. 
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1. Introduction 

This document comprises an outline proposal for a high speed D2B which works with 
an optical interface (Plastic Optical Fibre). The proposed device is = toown as the high 
speed D2B and is designated as C&C Electronics part number HSCI80U 1 

2. Objectives 

The objectives of the HSCI8001 development are as follows 

- To integrate many of the digital audio and video systems over a 
common data bus and come up with a suitable protocol that will be 
able to integrate them. 

• Baseline for the High Speed Conan 

• Use of Plastic Optical Fibre 

- Low cost LED Transceiver technology 

- Bandwidth requirements > 25 Mbs 

e Ring Topology for ease of installation, low cost Fibre Optics 
components and low power consumption... 

3.0 Requirement Constraints 
)) 3.1 Topology 

■ Point-to-point links 
» Linear T bus 

• Star system 

• Reflective star 

• Transmissive Star 



3.2 Line encoding 

There is a need for a more efficient encoding/decoding technique than 
what is currently used on the current Conan chip (BI-PHASE), One type 
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of encoding/ decoding techxuque that is currently used in FDDI which 
would be considered is the use of 4B5B encoding technique. This would 
provide the High speed network a reliable and efficient technique. 

* BI Phase encoding for current Conan design 

- 4B5B/8B10B 

3.1 Data rate Requirements 



« Parameters identified for the various digital audio video systems for 
integration over a common databus. The tabulated values indicate the some 
of the overriding parameters between systems.. 



Data Type 


Variable 

Bandwidth 

Requirements 


Common 
Frequency 


Frame Structure 


MPEG2 Audio 


up to 912kbps 


48kbps 




MPEG2 Video 


1.55 to 4Mbps 






DAB 


LSMbps? 


48kHz " " ~ 


16-32 Bits 


DVD 


! 1.08Mbps 




2048bytes Packet 


CD 


1.44Mbps 


44_lkHz 


16-24Bits 


ATM (Use this as 
a Transport for 
above Data Types) 






Similar to 5bytes of 
Header and 48 
Bytes of Payload 



3.4 Topology 

The communications network forms a backbone of roost architectural designs 
and hence the interconnections can influence the final design. Network 
topology fail iriaiiily mlo three categories. 

For the application that we are considering a Ring topology is still the 
preferred option as it means that ibe components available for the Optical 
network will still be relatively cheap and low power, rather then going to a 
relatively expensive star network. 

These point arc discussed further in the sections below. But it is highly likely 
that if Ln a large network environment if the system could not handle the delay 
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then a star nerwork could be the way forward if the components become 
available for the Plastic Fibre optics and arc relatively cheap. 

Point-to-point links: 

Point to point dedicated links are used in two ways. Firstly by a ****** link 
between each communicatog function. Secondly by a dedicate link between 
terminals and using electronics in each terminal to stnp off data which is 
addressed to that particular terminal and pass any further data to other 
terminal. 



■ ) ) 




fig. i 



Linear T- Bus 

These are relatively simple to implement if using voltage mode or current 
mode coupling and provide a broadcast medium that allows all terrmnals to 
simultaneously listen to the traffic on the network. This has been used in many 
of the electrical broadcast bus designs, but is far less popular for optical 
systems as the excess loss at each junction leads to extremely large link power 
budgets. 




These can split light from a fibre into a number of other fibres in a reversible 
manner, that is I:n or n:l. Many networks using fibre optics arc implemcn ed 
using a topology based on reflective and transmissivc star couplers. Bui ten 
cost penalty is higher. 
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Transmissive Star 




07-10-97 17:39 

7. OCT. )7~17:41 



p. 10 



R-900 Job-352 

NO. 1 230 P. 10 



B i^ i1pd Propo sal^ firBt embodiment of 

The following pages present * iirs - 

rate chann.l. < Mode cortipatible wl1 * the known 

5 rate channels ( Mode 0 > P oSed -sopTCOffiN" 

" CONAN " technology (and with tne p P 
technology having an increased capacity of fxxed 

rate channels). feature of 

A "MegaCONAN " chip is described, a key re 
in which isThe provision of dual processors. The fxrst 
10 which " the P proces sor corresponding to that used 

processor is a . . n7B 

L the exiting CONAN chip implementxng J*. 02B 

" e . ui th control of the f±~* data rate C-Kod. > 
/ata routing The second processor 
1S asynchronous ("Mode 1") data is a draxtal "9-1 
processor ,DSP> which can i»ple»ent. for 
rate conversion, audio DSP functions .such as "oibY ^ 
and can interface to on-chip or of f-chrp f or DVP and 
other data formats. 
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retailed Propo sal II 

The following page, present a modified embodiment, also 
providing both variable and fixed rate channels, but with 
5 flexible allocation of bytes within a common source data 
channel- Notable changes relative to Detailed Proposal 
I above are explained as follows: 

The delay at each network node in processing each 
10 frame of Proposal I would have been greater than 1 

sub-frame when using a network containing both D2D 
Optical and High Speed D2B network nodes. Since a 
conventional D2B Optical network can only handle a 
maximum of 1 sub-frame delay around the network 

15 such a "mixed mode" network would not have 

functioned correctly. In the Proposal II the 
maximum delay is 12 High Speed D2B bits <= 3 D2B 
Optical bits) thus up to a theoretical limit of 2 0 
nodes (16 when accounting for typical processing 

2 0 delays through each node) can be placed in a mixed 

mode network , 

in the Proposal I the allocation of circuit- 
switched synchronous traffic (Mode 0) and 
25 asynchronous packet based traffic (Mode 1) was 

fixed at 256 bits each. In proposal II the traffic 
can be allocated in a flexible manner from 100% 

3 „ a 4.^ mn* M«-.ri«> l in increments of 1 source 

byte from 0 source bytes to 60 source bytes in a 
frame. Total source data capacity is now 2 3.04 
MBPS at Fs = 48 kHz ( DVD sample rate). 

The frame structure allows transmission of 1 
complete ATM cell (53 bytes equivalent to a bit 
rate of 20.352 MBPS) in 1 frame as Mode 1 traffic 



30 
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20 

vnth 7 bvtes left for Mode 0 traffic (2.688 MBPS 
or, for example, 2 stereo digital CD channels). 
Thus the network can be used to transparently 
connect nodes with ATM data interfaces, if desired- 

Compatability is maintained as before by using a 
common control channel structure as currently used 
in D2B Optical sy terns (at a rate of 176.4 kbps at 
Fs 44.1 kHz) ("Conan" technology). 



When using a network in which all nodes are High 
Speed D2B Nodes additional control channel capacity 
can be added by using the 4 bits in the Right Pre- 
amble to increase the control channel capacity to 
15 352. B kbps at Fs = 44.1 kHz. 



Line coding efficiency is improved using 4B/5B line 
coding to reduce the overhead to just 20%. Thus 
the rate at which optical transceivers are required 
20 to be driven reduces to 29.4912 MHz (at Fs = 4 8 

kHz) as compared to 49.152 MHz for bi-phase 
encoding. 

Statistical multiplexing can be used to multiplex up to 
25 4 DVD channels onto the High Speed D2B Bus. This relates 
to calculating node buffer sizes in a distributed video 
transmission network. 
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n^-t-ai led -P-rnpnsal III 

A further example will now be presented, which differs, 
from Detailed Proposal II in various ways. 

The number of source data bytes per sub-frame is 
increased to 46, giving a continuously allocatable 92 
source data bytes per frame. The frame rate is fixed at 
48 kHz, giving a higher overall data rate than m 
10 Detailed Proposal II- 

Detailed Proposal III also provides more detail of the 
control of asynchronous channel allocation, and a package 
structure for data within the asynchronous channels. 

15 Although the variable width (asynchronous) channels and 
the fixed rate (synchronous) channels are again allocated 
within a single source data field from different ends, 
in this proposal the asynchronous traffic is allocated 

2 0 in the source bytes from the beginning of the frame, not 
the end. At the start of each block of 4 8 frames, 
asynchronous block headers are provided which indicate 
a channel ID and channel width which are fixed for the 
remainder of that block. The header for successive 

25 channels is found by counting through the source data 
bytes of the first frame in accordance with the width of 
each channel. The synchronous data channels are 
allocated from the end of the source data field. 



30 



Packets carrying 42 bytes of source data in this example 
nan also be grouped into packs of up to 25 6 packets. 
This can assist data handling in applications where 
larger segments of data, such as disk segments of 2 
kbytes are expected. A DVD source, for example, normally 
53 dsta ir. so-called PES cells of 1B8 bytes, which 
could, if desired, be grouped as pack of 5 of the 
proposed asynchronous data packets . 

A detailed description of Proposal III now follows. 
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System Description ted ln a rIng 



DVD Server 



Screen 4 



Screen 1 ; 



Screen 3 



Screen 2 



Example High Speed D2B System 



Depending on its function, each Device in the system can: 

• supply, receive or pass-through source data (e.g. digital aud l0 , v.deo etc.)- 

- se nd and receive control messages . 

To suppon the send.ng and receive controi ~s ^ 

The protocol, for con.ro! messa 6 e communication are define. ,n the D2B 

Specifications. 
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HS D2B Per £™J" cc lhc „. h Speed D2B System offers a gross data rale of 36.S64 
^JZV^stZ SLSIsS Mbps (or g anised ^ source bytes per High Speed 
D2B Frame). 

Hiqh Speed D2B Frame Structure 

The frame and sub-frame structures for High speed D2B arc shown in F.gures 1 and 2 
respectively. 

Block of 48 frames 




Fig 1 ; High Speed D2B Frame Structure 



The High Speed frame consists of two identical sub-frames, to Provide 
some compatibility with the earlier CONAN system as in Proposal II bat 
this is not essential. The frame rate is proposed to be fixed at *8 
kHz. Synchronous channels requiring a lower rate (e.g. CD audio, 
MPEG 1) can be padded and buffered accordingly within the synchronous 
data channels- 



) 
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First Subframc 




Transpafanl 
C hannels 

Second Subframe 




Transparent 
Channels 



: * reserved 



in other embodiments, the number o£ bits in the frame and hence the 
number of bytes in the source data field may be different. 



Error Protection 

The HS frame is protected by 2 parity bits, 1 in each subframe. 
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Source Data Transport 

V/h en ever source data (e.g. digital audio or video) needs to be transported over HS D2B, a 
source data connection must be established. This is called connection set-up. During the set- 
up, the required number of source data channels (bytes) are allocated from free channels 
within the HS D2B. For example, to carry a stereo audio signal from a CD player requires an 
allocation of 4 bytes. Source Data Connection protocols based on control messages are used 
for setting-up and removing connections- * 

For synchronous connections, this capacity remains allocated until the connection is removed. 
Synchronous connections have no superimposed framing or packet structure fc although applications 
are free to provide structure as desired. 

* For asynchronous connections, the connection set-up establishes the starting allocation. 
However this allocation can be varied during the lifetime of the connection as described in the 
section on Asynchronous Connection Blocks. 

When all the capacity has been allocated, attempts to build further connections will fail. 
When this happens, the controlling AVC must decide which existing connection(s) 

(synchronous or asynchronous) need to be removed to release enough capacity for the, new 

connection. The complexity of the allocation is hidden from the controlling AVC since each 
device is responsible for managing the allocation in its own output link (ring segment). 

Allocation of Source Data Capacity 

The source data field comprises the source data fields of the two sub-frames (with 46 + 46 
bytes capacity), flexibly partitioned into variable size sections as shown in the diagram. 

J The first part is allocated to variable-rate asynchronous transport: whilst the synchronous (or 
fixed-rate asynchronous) source data capacity is allocated starting from the end of the frame. 

* Source data routing is similar to that of the CONAN IC. but 

10 with a larger number of bytes per frame, and hence a far 

greater number of switching permutations. Connection building 
can be performed for example by protocols based on the 
disclosure of EP-A-0360338 (PHN 12676) and EP-A-Q4 32316 
(PHN 13189), adapted according to the ring topology protocols 
15 for this purpose are established using the control message 

frames to carry pre-arranged connection request instructions. 
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Source Data Fl&ld Struoture 

Left Subfrarne ™9 ht Subframe 

jpreambtej Soutcs Data i&s?<52s" Preamble] Source Doto |&s?aTus 



ACB1 



^ I ACBn; '. FrB 



SCB 



1 . ACBl.-ACBn are Asynchronous data Connection Blocks 

2. FrB represents free capacity for asynch (or sync) conns. 

3. SCB represents the synchronous data connection block 



A bytes (variable) 
92 - (A+S) bytes 
S bytes (variable) 



Asynchronous Connection Blocks (ACB) 

Asynchronous connection blocks are the means by which multiple variable-rate source daia 
connections can be carried on HS D2B. They are the containers for asynchronous connections 
within the HS frame, carrying the packet switched data. Since more than One ACB may be 
present in the same frame allowing multiple simultaneous asynchronous connections. 

The ACB is segmented over a block of 48 HS frames (aligned to the block of 48 frames used 
for transporting control message frames, see figure 1). Note that the ACB header appears only 
in the first frame of the block of HS frames. The size of the ACB is: ACB width * 48 bytes. 
Thus by varying the width of the ACB from block to block, the capacity occupied by an 
asynchronous connection can be varied, subject to the limit of the total capacity of the frame. 

Asynchronous Connection Block (ACB) 



S HS Frame 1 

HS ; HS Frame 2 
Block 



ACB 
ACB1 

ACB1 



'! ACBn] ; FrB SCB 
■ j ACBnj • " FrB i " SCB 

-! ACBn! : FrB i SCB 



Example Application 

The system shown on the first page consisting of a DVD server sourcing 4 different video 
signals could make use of the following source data field structure. The bit rate allocation 
may be varied for each connection as described in the section on Asynchronous Connection 
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Blocks Note that since the destinations for the video signals are distributed around the 
system noTall asynchronous connections need to be present in all links in the system. For 
example, the asynchronous connection carry the video signal to Screen I (video 1) needs only 
10 be present in the link from the DVD server to Screen 1. Each of ihe asynchronous 
connections could have a starting width of 24 bytes (per frame) and then could be varied 
individually as required for the variable rate video signal. 

Source Field Data Allocation for Multiple Video Sources 



Asynchronous Connections 



ACB1 
vicieb i 



acb2 

video? 



lilted 



^ACB4V-V . 



FfB 



SCB 



HS Frame Source Data Field (92 t>ytes) 



Error Protection 

The contents of the Asynchronous Data Connection Blocks rely on protection wiihin packets. 
Each Asynchronous Connection Block (ACB) is structured as follows: 

- Asynchronous-Connection Block (ACB)_ _ ...... 



! ACB Header 



ACB Data 



ACB-Header 

ACB ID <> bits 

Start of Packet flag 1 bit 

Reserved 1 bil 

ACB width 7 bits 

Reserved ' I bit 

Notes 

1. The^4CS ID enables a receiving device to identity the connection whose data is carried by 
this block. 

2. The Start of Packet flag indicates whether the first data byte 
of this ACB is also the first byte of a packet (flag set to 
1) or whether it is a continuation of a packet. This allows 
for longer packets than the type detailed below, for example. 

3. The Reserved fields is for future extensions. 

4. The ACB width field indicates the numuci of (coriocCUtive J 
bytes allocated to this asynchronous connection within each 
frame, encoded such that 1 means 2 bytes, 2 means 3 bytes etc 
The minimum width of two bytes ensures space for the header 
in the first frame of the block. The ACB width may be 
restricted Co ensure an integral number of packets within a 
block, where packet and/or frame sizes vary from these 
examples . 
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ACB-Data 

j ^ ^ ii ^ Arftc enurrp data is carried in the form of packets. The 
Within the capacity provided by ihe ACBs, source aaia i& 

packet format is described in the following section. 

• - ^ f . 1H c ; 7P r ran be different according 
The ACB header format and us field sizes can 

to the application. 

Free Capacity (FrB) 

synchronous connection blocks easj-ly. 

Synchronous Connection Block 

This block van be used co carry both synchronous signals e.g. 16 bit PCM audio at 48 I kHz or 
synchronous signals whose bit-rate is fixed. Changes to the contents and Size of ihis block 
made by setting up a new connection or moving an old connect,*, These 
operations are defined in the source data connection protocols [ 1 j. 



Packet Structure 

Asynchronous Data earned within either asynchronous or synchronous connections is 
format S into packets whose structure is described below. This provides frammg to a How a 
de 'ce receiving the data to identify the data and recover it correctly. Since each packet has its 
oTn ID !t is possible to interleave different streams of data over the same connection For 
example a particular connection might carry predominantly packets containing v.deo data 
interleaved with an occasional packet for control purposes. 



Packet Format 



Pocket Heoderl' 



Data 



P^rU-pr Tvne 



Packet ID 
Reserved 
Flow Control 
Start of Pack 
Remaining Packets 
Number of bytes used. 



2 bits (the remainder of the packet definition applies for type 0) 

3 bits 
1 bit 

1 bit 
1 bit 
8 bits 
8 bits 
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Packet Data 

Data 42 byies 

Error Protection 

Checksum/CRC 1 byLe 

Notes on Packet Header 

1- Packet Type identifies the format of the packet, for example 
longer packets may be provided for bulk data transfer, as 
opposed to real-time channels . 

2. Packet ID identifies the- type of data contained in the packet. 

such as audio/video/ gene ral data,, to assist routing in the 
destination device. Packet ID "7"H is reserved for control 
(e.g. connection management) messages, with low latency 
compared with the existing control message channel (CF bits) . 

3. Flow Control is used by a receiver of the data to indicate that its Rjc buffer is full (when this flag is set to 1). 
When (his is detected by the source of the data, it will normally suspend transmission. 

4. Remaining Packets indicates the number of packets renaming within the current pack (group of packets) 

5. Number of Bytes used indicates the number of bytes in this packet containing valid data 



P. 35 R-900 Job-352 

NO. 1 230 P. "35 

32 



Flow-Control _ . _ _ . . _ _ . 

The flow control mechanism implemented via the flag in the packet header, requires there to 
be a connection from the destination device back to the source device. This connection, which 
would be built as part of the connection set-up of the signal whose flow is being controlled 
can have a much reduced capacity (minimum 1 byte per frame) compared with e.g. the video 
signal to which it refers. It may for example have the same ACB ID 
and use the Packet Header format- A single byte channel Could also 
be allocated as an SCB . 

Alignment of a packet within an Asynchronous Connection Block 

The start of the packet is indicated by the Start of Packet bit in the ACB header. When this bit 
is set, the first byte of data following the ACB header is also the first byte of a packet. When 
this bit is not set, it indicates that the contents of the ACB are a continuation of a previous 
packet. 

Segmentation of the Packet 

The number of HS frames required for transmission of a packet is a function of the size of the 

then the packet will encompass foacket_size + size of ACB Header V /.ou uc * 

Diagram showing how packets are loaded into an ACB 

The diagram below showing how an ACB of width 6 bytes is loaded with packets (of size 46 
lyjriv^oy. i iiis /-iv^u iiuius a»A j^a»,n.cia ui which uic nrst iwo are snown (/\ ana a). i\oie thai the 
ACB header occupies the first two bytes and that between each packet are 2 reserved bytes 

group of by te S , according to the specified width of eac h channel. 
fL * <?° nnection becomes wider or narrower at the next ACB , the ACB 
for other connections are shifted up or down accordingly 
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Packets carried In an Asynchronous Connection Block (ACB) 
ACBn 

Fr. 1 [AGM H 1 . fACB_H PA1 j I PA2 ' i P A3 PA4 



Fr. 2 



pA5 i PA6 pA7 j j pA8 j • pA<? pAl O 



Fr. 8 | PA41 ! PA42 PA43 '; j PA44 1 j pA45 . pA46 

Fr . 9 [-^ijri r.Res:;; j pbi i rp??."] I p 03 pB4 



Fr , no | PB5 j pB6 pB7 j \ pB6 J | pB9 pBIO 

Fr. 16 |"pB4l | PB42 PB43 | (.PB45 pB46 



j Key 

I Fr. Frame 

j ACB_H ACB Header 

I Res, Reserved 

■ pai Packet A, first Pyte 



Packet Buffers 

Each HS D2B device which needs lo send or receive asynchronous data will require buffers 
for packets which have been received or are to be sent. The size of these buffers will be 
defined according to requirements. 
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DETAILED PROPOSAL IV 

A further proposal is now presented, which is 
substantially the same as the third proposal but 
5 defines certain mechanisms and communication channels 
for flow control in the asynchronous data* 

In particular a special connection signalling channel 
is built among the source data fields. Flow control 

10 implemented by each source adapts to minimum and 
maximum data rates signalled by other sources. A 
source data latency specific to the installation is 
accounted for in the flow control calculations and by 
means of a transition period between blocks. 

15 Mechanisms for determining the source data latency 
automatically are provided. 

Also buffer occupancy signalling" for -the- control 
channel is provided, to improve the efficiency of 
20 utilisation where one station such as the system 
master receives a disproportionate amount of control 
message traffic. 
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Features of High Speed D2B Optical (HS D2B) 

1 . Source Data Capacity of more than 43 Mbits/second, per point-to-point link 

a) Since each link is physically independent of any other link, this means that, by 
optimisation of relative device positions, the total system capacity can be much greater 
than the capacity of any single link. 

2. Supports transport of Asynchronous Data as well as Synchronous Data 

a) data can be carried regardless of its timing relationship with the system 

b) simpler to implement applications requiring asynchronous data 

3. Supports Variable-rate connections as well as fixed rate connections 

a) enabling more effective sharing of transport capacity between application whose 
demand is variable 

4. Same Control Message format as that of D2B Optical 

a) backwards compatibility for D2B Application Protocols 

b) applications requiring faster control message transport can now make use of 
asynchronous data connections to provide as fast a link as required 

HS D2B Performance 

Operating at a frame rate of 48 kHz the High Speed D2B System offers a gross data rate of 
43.78 Mbps and a net source data rate of 43.01 Mbps (organised as 1 12 source bytes per High 
Speed D2B Frame). 

2. Glossary 

HSD2B High Speed D2B Optical. This is the high bandwidth multi-purpose data 
communication system described in this specification. 

Variable rate connections These are source data connection whose use of the 

source data capacity can be adjusted to meet the requirements of the application without 
wasting source data capacity. They enable an efficient sharing of capacity between a 
number of applications whose need for bandwidth varies from time to time. This type of 
connection is suitable for variable bit rate signals such MPEG-encoded video streams from 
devices such as DVD players. Variable rate connections are asynchronous in general. 

Fixed Rate Connections These are source data connection whose use of the source data 
capacity is fixed when the connection is set up and is guaranteed through the lifetime of 
the connection. This type of connection is suitable for fixed bit rate signals such as PCM 
audio. There are two types of fixed connection: synchronous and asynchronous. 

Asynchronous Connection (Variable or Fixed Rate) The raw synchronous rate 
provided by channels within the HS D2B source data field can adapted (padded) to data 
streams which require lower delivery rates. The application may provide data for an 
asynchronous connection either at a constant rate or in bursts, subject to buffer capacities 
within the source and destination devices. HS D2B also provides a mechanism for 
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regulating the delivery of data over an asynchronous connection according to the demands 
of the destination rather than the source. For example a destination for CD-ROM data may 
consume data at a variable rate and can demand data whenever it needs. 

Synchronous Connections (Fixed Rate) These are connections which take full advantage 
of the raw synchronous rate provided by channels within the HS D2B source data field. 
There is no packet overhead associated with this type of connection and thus it is a very 
efficient use of system capacity subject to the constraint that the source must provide data 
at a rate which matches the system frame rate and the destination must be able to consume 
the data at exactly this rate. This type of connection could be use to transport PCM audio 
from a DAB receiver to an audio amplifier, for example. 



3. System Description 

A High Speed D2B Optical system consists of a set of devices which are connected in a ring 
topology via a series of point to point links. Each of these links is physically independent of 
any other link, 

Example System 

The diagram shows an example of a High Speed D2B system which supports video, 
navigation and telephone applications. 



DVD/DVD-ROM Server 
Nov. Controller 



Screen 1 



Screen 3 



Screen 2 



Exampie High Speed D2B System 

Depending on its function, each device in the system can: 

• supply, receive or pass-through source data (e.g. digital audiOi video etc.). 

• send and receive control messages 

To support the sending and receiving control messages, each device has two unique addresses 
an application-related address and a ring-position related address. It is also possible to 
broadcast a control message to ail devices or to a pre-selected group of devices . 

The protocols for control message communication are defined in the DIB Optical 
Specifications. 
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3.1 System Frame Rate 

The High Speed D2B System will operate at a single frame rate: 48 kHz 



3.2 High Speed D2B Frame Structure 

The frame structure for High speed D2B shown in the figure above contains . 













912 bits 








4 




- Source Data Field (1 12 Bytes) 




> 


Pre-amble 


CFO-3 


Aux 


Data 0 


Data 1 




Data 110 


Data 111 


6 




' 4 




B 




8 


6 








X 






> 



j SDB 


TR 


R 


R 







\ \ L 2 Reserved bits 
\ \ . . . Transition Period Indicator 

Start of Source Data Block 

Figure 2: Frame Structure 

The frame structure for High speed D2B shown in the figure above contains the following 

fields 

Preamble 

The preamble enables the receiver to recognise the start of an HS D2B frame and also to 
determine whether or not the frame is the starting frame of a CF block or not [The CF block 
structure, described in a later section, is used for Control Message Frame transport]. These 
preambles are as follows: 



Preamble 


Encoding 


Start of Block 
Start of Frame 


ESC '1011' 
ESC '1111' 



See the section on Line Encoding for further details. [Compared with D2B Optical, the HS 
D2B frame preamble has been extended from 4 to 8 bits to suit the line encoding. However 
this increase is cancelled by the use of only one preamble per frame compare with one 
preamble per subframe in D2B Optical. 

SDB Bit 

The first frame of the source data block is indicated by the SDB flag being set to 1 (by the 
System Master), in ail other frames SDB is set to 0. 

TrBit 

For the purpose of implementing variable rate connections, a Transition Period is defined for 
phasing in rate changes just prior to the start of a new source data block. The frames 
transmitted during the Transition period are marked by the Tr bit set to 1, whilst all other 
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frames have this bit set to 0. See the section Phasing in VCB Width Changes for farther 
details. 

TCO-3: Transparent Channels 

These bit-wide channels are subject to the same delay in each HS D2B Node as the data in the 
source data field. The transparent channel can he used, for example, to provide a network 
continuity indicator. Compared to D2B Optical, the number of transparent channel bits per 
frame has reduced (from 8 to 4) since HS D2B provides othei more flexible mechanisms for 
transporting asynchronous data over a much wider range of data rates. See the section on 
Source Data Connections for more details on this. 

CFO-3: Control Message Channel 

This channel is supported with 4 CF bits/frame, in exactly the same way as D2B Optical. 
Applications requiring faster control message transport can use fixed asynchronous source 
data connections as very high speed control channels, where the control messages can be sent 
within the same packet format as source data. For example, with one frame byte allocated to 
the connection, such a channel could offer a gross rate of 384kbits/sec, cf. the existing 
channel capacity of 192kbits/second. Such high speed channels could be dedicated either to 
one particular application or could be shared among applications, depending on how the fixed 
asynchronous connection is built. 

Source Data Field 

This carries all the data for source data connections. See the section on Source Data 
Connections for further details. 

3,2.1.1 Error Protection 

The HS frame is not protected. However note that the source data contained within the Source 
Data field may have its own protection where necessary. Also note that the control message 
frames have their own protection (see the D2B Optical Specifications for details). 

3,3 Frame Rate 

The High Speed D2B System operates at a frame rate of 48 kHz. 



4. 
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Block Structures in HS D2B 

There are two block structures in D2B 

• one associated with the transport of control messages 

• one associated with the transport of source data 

4,1 CF Block 

A block of 48 High Speed Data frames is used for the purpose of transmitting control 
message frames, carried via the 4 CF bytes in each HS D2B frame. The start of a block is 
indicated via a special preamble which replaces frame preamble every 48 frames. 



CF Block of 48 HS D2B frames— ► 




Control frame (192 bits) 



< 1mS@ „ > 

Figure 3 : CF Block Structure 

4.2 Control Message Frame 

The control message frame is identical to that in of D2B Optical Block, apart from an 
expansion of the arbitration field to 4 bits and a corresponding contraction in the reserved bits 
at the end of the frame. 



4.2.1 Control Frame 

The control frame is assembled from and aligned with a block of 96 sub-frames, i.e. the first 
two bits of a new control frame are taken from the sub-frame with a block preamble, and 
subsequent pairs of bits are taken from Subsequent sub-frames to build up a control frame. 
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Controi Frame 

The fields of the control frame are: 



Arbitration bits ; 

This four bit field is used to signal whether or not the current control message frame is 
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free. It is also used to indicate the occupancy of the system master's Rx Buffer. The first 
two bits (bit 0 and bit 1) of the arbitration field are reserved. The second two bits indicate 
the functions listed below. 



Function Indicated 




Rit ^ 


Control message frame is free & System 
master's RX buffer is free 


0 


0 


Control message frame is free & System 
master's RX buffer is occupied 


0 


1 


Reserved 


i 


0 


Control message frame is occupied 


l 


1 



• Destination Address 

This is the 12-bit device address of the destination of the message, in the range ( 000'H to 
'FFF'H. The sending device writes this into its message transmit buffer for transmission. 
Certain addresses and address ranges have special meanings (see section 2.6). 

• Source Address 

This is the 12-bit device address of the sender of the message, in the range 'OOO'H to 
'FFF'H. The receiving device can read this from its message receive buffer after 
reception. Certain addresses and address ranges have special meanings (see section 2.6). 

• Message Type and Length 

Two 4-bit fields normally used to indicate the type/length of the message. These bits are 
transported transparently by Conan. 

e Data 0 to 15 

The message data. All 16 bytes are always transported. The Message Length normally 
indicates how many of the 16 bytes are actually valid for the message. The sending device 
writes this into its message transmit buffer for transmission. The receiving device can read 
this from its message receive buffer after reception. 

• CRC 

A 16-bit Cyclic Redundancy Check value is used to verify that the control frame has been 
transported without error. The CRC is generated by Conan automatically on message 
transmission and checked by Conan automatically on message reception. 

• ACK/NAK 

Acknowledge and Not Acknowledge (2-bits each) indicate successful message 
transmission. The use of separate ACK and NAK flags allow reliable point-to-point and 
broadcast message transport. The flags are automatically filled by the destination device(s) 
(if present) and read by the sending device. 

• Reserved : 8 bits reserved. 

Bit order within Control Frame Fields 

The data is always transmitted and received LSB first in each field. 



4.3 
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Source Data Block 

A block of 108 HS D2B frames is used for the purpose of transmitting source data, 
supporting the packet structure for the asynchronous connections (both fixed and variable). 
Fixed Synchronous connections carry a constant amount of source data in each frame 
regardless of the position of the frame within a Source Data Block and are thus not dependent 
on the source data block structure. The start of a block is indicated via the SDB bit in the 
header of the D2B Optical frame (See the Frame Structure in Figure 2). 

(Note that the Source Data Block is not necessarily aligned with the CF block described in the previous section) 



Source Data Block of 108 HS D2B frames - 




[Key: w ".V. Width of connection in bytes. [For variable-rate connections: w is variable, 

j and the connection segment shown above is then called a Variable Connection 

j block (VCB)] 

• N Number of packet slots. Since each packet slot contains 108 bytes: N=w 

\ * Note that the diagram shows only an example of the use of padding. Padding 

. can occur at any point with a variable or fixed connection block and be of any 
i duration up to the duration of the connection block. 

Figure 4 : Source Data Block Structure 

Bit order within Source Data Bytes 

Source data is always transmitted and received MSB first in each byte. 



5. Line tncociing 

The line coding scheme for High Speed D2B is 4B/5B as described below. 
4B/5B encoding provides the following features: 

• Provide an average of over 3 transitions per 5 bit symbol, to ensure easy clock recovery in 
the receiver 

• Run length is limited to less than or equal to 5 
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Free of DC frequency on average 



5.1.1.1 Within the Sender 

The HS D2B Frame is segmented into nibbles. Each nibble (4 bits) of an HS D2B Frame to 
be transmitted is translated into a 5 bit symbol as shown in the table below and then NRZI 
encoded for transmission. 



HS D2B Frames 



4B/5B Encoding 



NRZI Encoding 



Physical Medium 
Interface (FOT) 



5.1.1.2 Within the Receiver 

At the receiver, the received serial data is NRZI decoded and the resulting 5-bit symbols 
decoded to form a data nibble. The nibbles are then re-assembled into an HS D2B Frame 





Physical Medium 
Interface (FOT) 


NRZI Decoding 4B/5B Decoding HSD2B Frames 







5.1.1.3 4B/SB Symbol Table - - 

Each symbol of the code is composed of 5 bits. Of the 32 possible symbols, 17 are valid in 
this implementation and 15 symbols are invalid. The 17 valid symbols represent 16 -4 bit d 
nibbles (hex 0 through F) and the one Escape (X) code. The Escape code is used in the 
preamble of the HS D2B frame (see the following section. The table below lists the 4 - bit 
nibble to 5 bit symbol conversions. 



Note: The binary value for 4-bit data nibble and 5 bit symbol encoded are shown as most - 
significant bit first (i.e. at left). 



Data 


Symbol 


Data 


Symbol 


Data 


Symbol 


Data 


Symbol 


0000 


inn 


0001 


01001 


0010 


01010 


0011 


01011 


0100 


oom 


0101 


01101 


0110 


oino 


0111 


01111 


1000 


10010 


1001 


11001 


1010 


11010 


1011 


11011 


1100 


10111 


1101 


11101 


1110 


11110 


1111 


10101 









Null Data/Padding 

Nibbles which do not contain null i.e invalid data (e,g. padding) will be indicated via the 5B 
value ('1001 TB). 

NRZI encoding/decoding: 

Each bit of the 5 bits symbols produced by the 4B/5B encoding is further encoded such that 
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' 1' is encoded as a transition ( 0 ->1 or 1 ->0) and *0' is encoded as a lack of a transition, as 
shown in the diagram below. 



Bit Value 


1 


1 


0 


0 


1 


i 1 


0 


1 


NRZI encoded 




















output 



























The serial data rate following NRZI encoding matches the serial data rate prior to the 
encoding, thus the use of NRZI encoding does not reduce the data transport capacity of HS 
D2B. 



6. Source Data Transport 

HS D2B can accommodate 3 different types of source data connections: 

• Fixed-rate synchronous connections 

• Fixed-rate asynchronous connections 

• Variable-rate asynchronous connections 
Fixed-Rate Connections 

These are source data connections whose use of the source data capacity is fixed when the 
connection is set up and is guaranteed through the lifetime of the connection. This type of 
connection is suitable for fixed bit rate signals such as PCM audio. There are two types of 
fixed-rate connection: synchronous and asynchronous. 

Synchronous Connections (Fixed-Rate) 

TTiese are connections which take full advantage of the raw synchronous rate provided by 
channels within the HS D2B source data field. There is no packet overhead associated with 
this type of connection and thus it is the most efficient use of system capacity subject to the 
limitation that the source must provide data at a rate which matches the system frame rate and 
the destination must be able to consume the data at exactly this rate. This type of connection 
could be use to transport PCM audio from a DAB receiver to an audio amplifier, for example. 

Asynchronous Connections (Variable or Fixed Rate) 

Source data is carried within a packet structure which allows the raw synchronous rate 
orovided by channels within the HS D2B source data field to be adapted (padded) to data 
which requires delivery at some lower rate. The application may provide data for an 
asynchronous connection either at a constant rate or in bursts, subject to buffer capacities 
within the source and destination devices. HS D2B also provides a mechanism for regulating 
the delivery of data over an asynchronous connection according to the demands of the 
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destination rather than the source. For example a destination fox CD-ROM data may consume 
data at a variable rate. 

Where the bit-rate of data to be delivered over an asynchronous connection varies over a wide 
range e.g. by a megabit or more, a variable-rate connection should be used. This type of 
connection enables any spare capacity released by one variable connection to be made 
available to other variable connections which can make use of it. The flow control for these 
connections enables a destination to specify the rate (or range of rates) at which the source 
should deliver data to it. 

6.1 Connection Set-up 

Source Data Connection protocols based on control messages are used for setting-up and 
removing connections. These are described in [1] and [2]. 

Whenever source data (e.g. digital audio or video) needs to be transported over HS D2B, a 
source data connection must be established- This is called connection set-up. During the set- 
up, the required number of source data channels (bytes) are allocated from free capacity 
within the source data field of the HS D2B frame. For example, to carry a stereo audio signal 
from a CD player requires an allocation of 4 bytes (2*16 bit samples) per frame. 

When all the frame's source data capacity has been allocated, attempts to build further 
connections will faiL When this happens, the System Master AVC must decide which 
existing connections (fixed or variable-rate) need to be removed to release enough capacity 
for any new connection. The System Master AVC is not aware of which -parts of the source 
data field are allocated to which connections, since each device is responsible for managing 
the allocation in its own output link (ring segment)- However, the System Master AVC can 
find out the type of source data delivered by a particular source, via subdevice status (the 
Source Data Type status report). The rules by which the System Master AVC selects which 
connections to remove first are not specified in the D2B Protocols, but form part of the 
Application. 

For variable-rate connections, the connection set-up establishes a reserve allocation, although 
the actual allocation from source data block to source data block can be varied during the 
lifetime of the connection as described in the section on Variable Connection Blocks. [The 
' reserve allocation of variable rate connections is used for the purpose of calculating whether 
there is sufficient capacity to build a new connection. This means that a new connection 
(variable or fixed) would not be built if it meant that a source would have to reduce the VCB 
width for a variable rate connection below this reserved width.] 

6.2 Partitioning of the Source Data Field 

The source data field is partitioned into sections carrying the different types of connections as 

The first section of the source data field is allocated to variable-rate connections (if there are 
any): whilst the fixed-rate connections are allocated capacity starting from the end of the 
source data field. Any capacity remaining is grouped into the section marked 'Free\ 
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Source Data (112 toytes) 



| VCn J r'Free'l f*FC | 
Figure 3 Partitioning of the Source Data Field 

1. VCl-.-VCn are Variable-rate Connections kbytes (variable) 

2. FC represents all the Fixed-Rate Connections F bytes (variable) 

3. Free represents free capacity for VCs or the FCs 112- {V+F) bytes 

7. Variable Connections 

These are source data connection whose use of the source data capacity can be adjusted to 
meet the requirements of the application .Variable rate connections are asynchronous in 
general. The bit-rate provided by a variable rate connection depends on the number of source 
data bytes allocated to that connection within each frame, referred to as the width of the 
connection. 

The format of data carried within a variable connection is a matter for the application. 
Padding must be inserted into the transmitted variable connection data at any time when there 
is no data available from the source. 

The bit-rate (i.e. the width of a variable connection) cannot be varied from HS frame to HS 
frame, it can only be changed on source data block boundaries i.e. once per 2.25 millisecond 
at a frame rate of 48 kHz). Thus within a source data connection block, the width of a 
variable connection remains the same. 

7.1 Variable Connection Block 

A Variable Connection Block (VCB) is the collection of data for one variable-rate connection 
(VC) that is transported within one Source Data Block. See the section on Source Data Block 
Structure. 

Variable Connection Blocks may be viewed as containers for data carried in a variable-rate 
connection. 

i tv*^ orviA^r>f *-»f iirT, ^ VCB is; VC3 width * 108 bytes [les* the header size szid ssiy 
restriction imposed during the Transition Period, see Phasing In VCB Width Changes], 
Thus by varying the width of the variable-rate connection (VC) from one source data block 
to another, the capacity allocated to a variable-rate connection can be varied, subject to the 
limit of the total capacity of the frame. 
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07-10-97 17:39 

7. OCT..J997 1 7:5 1 



P-49 

46 



R-900 Job-352 

NO, 1 230 P. 49 



2. The VCB header indicates the VC width and a reference number for that connection (the 
VC ID). 

3. The contents of the Variable Connection Blocks are unprotected. 



VCB Header 

VC width 9 bits 

VC ID 6 bits 

Resen/ed 1 bit (=0) 

Err Protection (N-K) 16 bits 

Reserved 1 bit (~0) 



Notes 

1 . The VC width field indicates the number of (consecutive) bytes allocated to this variable- 
rate connection within each frame, encoded such that 4 means 4 bytes, 5 means 5 bytes 
etc. The VCB width field must be set to a minimum of 4 for error protection purposes. 
When the VCB width field is set to 0, this indicates that the remainder of the variable 
connection part of the frame is free. Note that when a VCB has a width of zero in a source 
data block, e.g. because its destination cannot accept further data, the VC is not carried in 
the frame and therefore has no VCB header. 

2. The VC ID enables a receiving device to identify the connection whose data is carried by 
this block. 

3. BCH Encoding protection (3 1,16) is used to protect the preceding fields against up to 3 bit 
errors, allowing both detection and correction. - - _ 

4. The Reserved field is for future extensions and should be set to zero 



SoL/rce 
Data 
Block 



HS Frarne 1 
HS Frame 2 

HS Frame 1 08 



VCB 



H V Cn 1 [_Free | [ FC 



VCn "I I Free] [ FC 



VcY i v [~VCn "] | Free J [_FC 



Figure 4 Structure of a Variable Rate Connection Block 

7.2 Example Application: Multiple Video Sources 

The system shown on the jfirst page consisting of a DVD server acting as a source for 4 
different video Signals could make use of the folio wing source data field structure. The bit 
rate allocation may be varied for each connection by varying the number of bytes allocated to 
the Variable Connection in each source data block (the width of the variable connection). 
Note that since the destinations for the video signals are distributed around the system, not all 
variable-rate connections need to be present in all links in the system. For example, the 
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variable-rate connection carry the video signal to Screen 1 (video 1) needs only to be present 
in the link from the DVD server to Screen 1 . Each of the variable-rate connections could have 
a starting width of e.g. 24 bytes (per frame) and then could be varied individually as required 
by the rate of consumption in the MPEG decoder in each screen. 

Source Field Bata Alfiecatien fer Multiple Video Sources 

v«iwtoto-R«rt9 Connections 



VCl 




VC2 




VC3 




VC4 




Free 




FCB 


vrtee 1 




vide* 2 




vWe* 3 




vlolee A 











HS Fr*me Source Field (112 toytes) 

Figure 5: Example of multiplexed video connections 

7.3 Variable Rate Flow Control Mechanism 

Whilst a source device directly controls the rate which is allocated to its connection(s), the 
source device needs to receive feedback from the destination about the rate required to 
prevent the receiver's buffers from either becoming empty (a serious problem for real-time 
signals such as audio and video) or from overflowing (where the data is lost). 

The mechanism enables the destination to report the minimum quantity of data that it requires 
to have delivered during the next block for the application to survive without interruption. 
The destination also reports the maximum amount of data that it can receive without its buffer 
overflowing. This latter information can be used to take advantage of spare capacity to spread 
the 'load' on the data transport capacity. 

This mechanism enabled ihe bus capacity to be shared fairly between a number of competing 
variable-rate connections according their requirements and their priority. 

Signalling Channel 

When variable-rate connections are to be used within the system, there needs to be a 
Signalling Channel established for the purpose of transporting messages for signalling the 
delivery rate requirements of the destinations of these connections. This connection signalling 
channel takes the form of a fixed-rate synchronous connection occupying at least 1 byte of 
each HS frame, within the Fixed Connection section of the frame (see 6.2 Partitioning of the 
Source Data Field). This channel must exist around the entire ring. This signalling channel 
can be built as soon as the system lias started up. 



7.3.1 Messages within the Connection Signalling channel 

The Connection Signalling channel carries a packet, containing a message for each of the 
current variable-rate connections. The messages are created by their sources in the order: 

1 . in which those source devices are positioned in the D2B Optical ring and, 

2. in order of connection ID (VC ID) (where a device is a source of multiple connections) 
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For example, consider a system with 3 current connections: two from the device at ring 
position 1 (VC IDs 1 and 2) and one from a device at ring position 2 (VC ID 4). Within the 
Connection Signalling packet, the following messages would be found in the order shown 
below: 

1. Connection signalling messaee I (CSM1) from the source at ring position 1, with VC ID 

2. CSM2 from the same source, with VC ID 2, 

3. CSM3 would be from a source at ring position 2, VC ID 4 

4. The messages CSM1 to CSMN would then be transmitted again to allow devices to see the 
completed messages (since the messages will have been modified by their destinations 
during their first pass around the ring.) 

[Devices are allocated a ring position, relative to the System Master, such that the System 
Master is at position 0, then in the direction of light propagation, the next device is at 
position I etc.] 



r^PD-l'S He«ierJ | Cg»hn'Slft Me ss " 1 J . N J | Mo dified CSM 1 „ N J [ Pcttffiljng | 
Figure 9: Connection Signalling Packet Format 

When a source device has initiated the building of a variable-rate connection, the source, 
device writes the following structure into the first free message slot within the signalling 
channel. If the first free slot also happens to be the first slot following the start of a source 
data block (108 HS frames), then the source also creates the packet header as shown below. 

The signalling channel then carries a packet, with the following format (starting with the first 
byte following the start of a block). Note that for the transmission of the modified Connection 
Signalling Messages, the source device in each case must store all the fields it receives from 
its first message and then transmit these in the next available message slot. Note that no 
device is permitted to overwrite any of the fields in this repeated message: thus all devices 
will have a chance to see this message in its final state. 

7.3.1.1 Connection Signalling Packet Format 

(Packet Header, type 2, (108 bytes in length)) 
Packet Header 

Packet Type 2 bits (^10, for type 2) 

racket iu 3 bits (set io OOi) [i signifies connection signaling] 

Reserved 3 bits (=000, not used) 

Packet Data 

0{ <Connection Signalling Message> }n <padding> 

Connection Signalling Message 

VCID 6 bits (or Connection ID) 

Priority of Connection 2 bits 

Min VC width 7 bits 
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Max VC width 

Reserved 

R&ser/ed 



r bits 
1 bit 
1 bit 



Padding 

The remaining bytes within the packet, following the connection signalling messages, are 
reserved. If 21 connection signalling messages are present (the maximum number), there are 
2 remaining bytes. 
Notes on the above packet format 

1 . Packet Type distinguishes the format of the packet from that of other types (inch header) 

2. Packet ID indicates the nature of the message carried by this packet, i.e. connection 
signalling in this case. 

3. VC ID: matches the connection to which this message refers. A VC ID of 0 indicates that 
this message slot is unused. 

4. Priority of Connection Flag indicates the priority of this signal is real-time (high priority) 
or non-real time. If real-time, the flag is set to '3' (high priority),, otherwise it is set to a 
value between '0 5 and { 2\ 

5. Min VC width. This field is written by the destination of the connection. It indicates the 
minimum width required for the specified VC within the next source data block to ensure 
that the destination's buffer will not be completely emptied. When a connection is not yet 
complete, this value remains 0, since there is no destination yet. When the connection is 
active, the minimum VCB width varies between 0 and the maximum width of an VCB. 
The first non-zero value written by the destination, following set-up of a connection, 
indicates the reserve capacity which should be allocated to this connection. 

6. Max VC width. This field is written by the destination of the connection. It indicates the 
maximum width required for the specified VCB within the next Source data block to 
ensure that the destination's buffer will not overflow. The destination must calculate this 
requested maximum VC width on the expected buffer level at the end of the current source 
data block [in which it is making the request]. This is to prevent the buffer overflowing. 
The destination will be able to calculate the expected buffer size from the VC width which 
has been allocated by the source within the current source data block. When a connection 
is not yet complete, this value remains 0, since there is no destination yet. When the 
connection is active, this width varies between 0 and maximum width of an VC. [1 is not 
allowed, due to the size of the VCB Header]. [In the event that the Max VC Width is less 
than the Min VC Width (only possible with multiple destinations), the Max VC Width 
takes precedence.] 

7. The Reserved field is for future extensions. 

7.3.1.2 Limit on the Number of Variable Rate Connections 

There is a limit on the number of variable rate connections which can be supported 
simultaneously within a system: due to the size of the connection messages and the need to 
repeat the messages twice. 

The limit may be calculated as follows: 

((width of conn. sig. channel)* (1 08 - Num. of frame buffers) -CS Pckt Hdr size) / (message size * num. of transmissions) 
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1 . The width of connection signalling channei is normally I byte. The size of the Connection 
Signal Channels packet header is 1 byte. The Number of frame buffers in the system is 
equal to twice the number of sources in the system (including System Master), since each 
source contributes two frame buffers to the system. The message size is 3 bytes and there 
are 2 transmissions. Thus for a system containing 10 sources, the number of variable rate 
connections supported is: 

(108~(10*2)-l)/9-= 87/9 = 9 (when rounded down to the nearest integer) 
7.3.1.3 Role of the Destination 

The destination must supply the rate requirement, by writing minimum and maximum VC 
widths into the appropriate connection signalling message fields, to enable the source device 
to decide how much bit rate capacity to allocate for the next Source Data block (108 frames). 
The destination must also supply its ring position. [In the case where more than 1 destination 
is present, a destination is allowed to overwrite a previous destination in ring order, under the 
following conditions: (I) the Ring position may be overwritten if this destination is further 
from the source ; (II) the Minimum requirement may be overwritten if this destination has a 
higher minimum requirement- (III) the Maximum requirement may be overwritten if this 
destination has a lower maximum requirement. 

Immediately after a variable-rate connection has been set-up, the destination is responsible for 
writing the reserve allocation requirement into the Minimum requirement field of the first 
connection signalling message for the new connection. 



7.3.1.4 Rules for Sources when transmitting Connection Signalling messages 
Connection signalling messages are modified by the relevant destinations during their first 
pass around the system,. These connection signalling messages must be transmitted again, in 
their modified form, by the sources which generated the original messages. 

A source which is generating connection signalling messages must: 

1. wait for an unused connection signalling message location (indicated by VC ID = 0) 
before transmitting a connection signalling message on its output (sending the message). 
[This rule applies both to the original transmission and also to repeat transmissions]. 

2. when it receives its own connection signalling message back after transmission, replace 
each byte of its own message with a byte containing 0 on its output. This frees the 
connection signalling channel for use by downstream sources. 

7-3.2 Controlling a Variable Rate Connection 

For determining the rate to be allocated to an variable-rate connection, the source of each 
variable-rate connection must take into account both the requirements of the destination(s) of 
that connection and also requirements of the other source data connections with which the 
system capacity must be shared. 

There **re two st^.*^^-^ +v»»=* nmrpcc- 

1 . a determination of which other source data connections must be taken into account 

2. a determination of how much capacity (rate) should be allocated to each of these 
competing connections 
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7.3.2.1 Determination of Relevant Source Data Connections 

The source must consider all the source data connections (fixed as well as variable) which 
affect the capacity that can be allocated to its own variable-rate connections, since the system 
capacity must be shared between all of these connections. 

7. 3.2. J. J. J Global Search 

The source looks at the ring positions of sources and destinations for each of the other source 
data connections in the ring. It then analyses the overlap relation between each of these 
connection and its own connection: either direct overlaps or indirect (where a connection 
which overlaps this connection is itself overlapped by another connection. See Reference 3 
for an analysis of this procedure. The ring positions of sources and destinations will be 
provided via a Connection status reports (to be defined). One of these will be broadcast by the 
System Master following successful completion of set-up for each source data connection. 

7.3.2.2 Determination of Capacity for each Connection 

The source data field capacity must be shared between all source data connections both fixed 
and variable-rate, with the fixed rate connections having a guaranteed share. If the capacity 
was unlimited, all destinations would be given the maximum capacity (VC width) that they 
have requested. However, since capacity is limited, the source must apply an algorithm to 
share the available variable rate capacity between the competing connections in such a way 
that: 

1 . there is the least risk of interrupting an application and 

2. the available system capacity is used very efficiently, allowing more simultaneous 
applications to be supported. 

7.3.2.2.1 Stages in the Sharing Calculation 

1 . Allocate the minimum requested capacity 

a) first to all the high priority connections in order of VC 

b) secondly to the lower priority Connections 

2. Allocate the remaining capacity: (There are 3 alternatives here) 

a) weighted according to the remaining requested capacity for each connection (max-min) 

b) round robin allocation of to each connection in turn 

c) allocation of the full requested capacity to each connection in turn 

7.3.2.2.2 Stage 1 : Allocation of Minimum Requested Capacity 

1 . The source device calculates the total available width (capacity) by forming the sum of all 
current VC widths and the free width. 

2. The source device should 'allocate' the minimum requested width to each of the relevant 

^ ^ „ ns*,-** n~>. 

a) first, to high priority connections in the order in which they are represented in the 
signalling channel 

b) to low priority connections, in signalling channel order 
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This stage ends either when there is no remaining available capacity or when all relevant 
connections have been allocated their minimum requested capacity. 

7.3.2.2.3 Stage 2: Allocation of Minimum Requested Capacity 

If any capacity remains following Stage 1, it will be allocated to the relevant connections 
according to the following method. 

Allocation to each connection in turn 

In this method the full requested allocation is given to each high priority connection in 
connection signal channel order until all the capacity is used or until all high priority 
connections have their full requested allocation (Max VC Width, including the allocation 
from Stage 1)- 

If any capacity remains, then it is allocated giving the full requested allocation to each low 
priority connection in connection signal channel order until all the capacity is used. 

7.3.2.2.4 Implementing the VC width which has been calculated 

1. Each source may only set the width of its own VC, according to the allocation calculation 
described above. Further if the new width is less than the width in the current block, then 
the width reduction must be phased in. See the section Phasing in VC Width Changes- 

2. Each source must remove the VCs for any destination which precedes it in ring order and 
must shift the higher VCs down to fill the gap left by the deleted VC(s). 

7.4 Phasing in VC Width Changes 

Because of the presence of source data buffers distributed around the ring (whose number 
depends on the ring configuration), the changes in VC width cannot in general be completed 
within a single frame. Each source must start making adjustments to meet the calculated VC 
size for the next Source Data Block at the start of an interval called the Transition Period. The 
Transition Period is the period during which the master is transmitting frames in the old 
source data block whose contents will be copied by the system master into the first frames of 
the new source data block. 

Frames transmitted by the system master during the transition period are marked via the Tr 
bit in the HS D2B frame. When loading frames which are in the Transition period, sources 
which are due to reduce their VC size in the next source data block must use Only the width 
of VC which will be allowed in the next block (i.e. bytes are wasted at the end of the VCB 
within each of the frames in the Transition Period. Sources which are due to increase their 
VC size may only do so in the first frame of the new source data block. Note that 

1 . All connection signalling messages must complete their final pass around the ring before 
the start of the Transition period. This means that the number of simultanvariable 
connections 

2. During a period equal to the transition period following the start of a new source data 
block.. VCs whose size has increased contain only the same amount of data as the 
corresponding (smaller) VCs in the previous source data block. This only applies to the 
section of the ring between the Master and the source for that VC. 

3- The number of frames in the Transition Period is equal to the number of sources * 2, 
where the system master is always counted as a source. 



07-10-97 17:39 

7. OCT. la-Q*? 17:53 



07-10-97 17:39 

7. OCT. 1097 17:54 



NO. 1230 P. 56 



53 



Source Data Block 



Transition Period 



j Frame 1 



Frame T 



[ Last Frame j 



Frame 1 



Example: VC1 changes from 10 to 8 bytes wide 

| |_ VC 2~~7I 



V C 1 
1 0 bytes 



-> -4- 



1 0 bytes 



Frame T 
Transition Period 



VC 1 



VC 2 



< >>.<*- 

1 0 bytes 



10 bytes 

Unusable Capacity 



Frame 108| VC 1_ 
< ■ 



[ " VC 2 



1 0 bytes 



Frame 1 



VC 1 

8 bytes 



10 bytes 



V C 2 
1 2 bytes 



New Source Data Block 



7.5 Example of Variable Rate Connections 

In the diagram below, connections i and 2 and 3 overlap over a number of segments in the 
ring. Thus the capacity allocated to connection 1 will limit the allocations which can be made 
for Connections 2 and 3. To ensure fairness of sharing bus capacity (and thus maximise the 
number of simultaneous applications supported within the system) the source of connection 1 
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should also take into account the buffer occupancies and priorities of connections 2 and 3, 
when deciding what bit-rate it should use for its own output. 

1. Connection 1 (Source 1 to Destination 1) is for a compressed video signal (a real-time 
signal, therefore high priority) 

2. Connection 2 (Source 2 to Destination 2) is for map data from a CD-ROM (non-real time, 
therefore low priority) 

3. Connection 3 (Source 3 to Destination 3) is compressed video (high priority) 



..-[Source 1 



Dest. 1 




Source 2 



Dest. 3 



Source 3 




1,3 



Dest. 2 - 7,2,3 



Figure 10: Overlapping Connection Example 



Initialisation 

Each connection is set-up with a reserve VC width determined by the expected rate or by the 
size of the free block, from which bytes are allocated for the new VC. 

Suppose, for this example, that the total available width for VCs is 80 bytes (including the 
Free block), since the remaining bytes of the source data field have been allocated to the 
fixed-rate connections. 

Actions of source 1 

Suppose that at the start of Source Data Block n, 

1 . Destination 1 decides that it needs a width which is a minimum of 5 and a maximum of 1 0 
bytes. [This will lead to a delivery of between 510 and 1020 bytes during the Source data 
block, assuming that at least the minimum requested capacity is available.] 

2. Destination 2 decides that it needs a width which is a minimum of 10 and a maximum of 
50 bytes (VCB width). 

3. Destination 3 decides that it needs a width which is a minimum of 20 and a maximum of 
40 bytes (VCB width). 

The calculations given in stages 1 and 2 (alternative 1) apply to the calculation in this 
example. 

Source 1 is aware of the requirements of all these destinations and tries first to allocate the 
maximum requested widths (total 10+50+40=100), but finds that this exceeds the available 
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width (80). Then source 1 allocates the minimum requested capacity to each connection (5 + 
10 + 20 = 35) and then shares the remaining capacity (80-35^=45) between the high priority 
connections (from source 1 and source 3), leading to an additional width of 

m 5 for Source 1 

* 40 for Source 2 

• 0 for Source 3 

© There is no remaining width 

Finally source 1 calculates the VCB width for connection 1: 5+5-10 bytes. This change 
will be phased- in as described above. 
Actions of source 2 

Source 2 will have received the same information from destinations 1,2,3. It will perform the 
same calculation as source 1, leading to a VCB width of 10+40 = 50 bytes which it will set 
for connection 2. This change will be phased-in in as described above. 

Actions of source 3 

Source 3 will have received the same information from destinations 1,2,3. It will perform the 
same calculation as sources 1 and 2, leading to a VCB width of 20+0 = 20 bytes which it will 
set for connection 3. This change will be phased-in in as described above. 

8. Free Capacity (Free) 

The free capacity is treated as a Variable Connection (VC) with ID = 0. 



9. Fixed Connections (FC) 

This last section of the source data field can be used to carry both synchronous signals e.g. 1 6 
bit PCM audio at 48 kHz or asynchronous signals whose bit-rate is fixed. Changes to the 
contents and size of this block can only be made by setting up a new connection or removing 
an old connection. These operations are defined in the Source Data Connection Protocols 
[l]and in . Source Data Connection Protocols: Extensions vO.l [2] 

9.1 Fixed-Rate Asynchronous Connections 

A fixed-rate asynchronous connection carries unformatted source data, modified only by the 
insertion of padding to match the bit-rate of the connection to the requirements of the 
application. 

Padding 

the source. The insertion of padding reduces the effective bit-rate of the connection to match 
the output from the source. 

Flow Control 

In some applications, the source is able Lo deliver data at a range Gi uit-rate an^ it is tuC 
destination which must regulate the bit-rate in order to avoid overflow and thus loss of data in 
the receiver. The flow control mechanism enables the receiver to feedback a stop/continue 
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indicator to the source. The stop indicator forces the source to stop transmitting data anu to 
fill the connection with padding until a continue indicator is received 

9.1.1 Fixed Rate Flow Control Mechanism 

When a fixed-rate asynchronous connection is built, the system allocates a single bit within a 
flow control connection byte to carry the a stop/continue indicator. The flow control 
connection is built around the ring from the System Master to the destination. [The System 
Master may build this flow control connection any time after the system initialisation is 
complete following start-up. 

The bits are allocated in connection ID order, when fixed-rate connections are set up. The bits 
are released when fixed-rate connections are removed, thus becoming available for use with 
new connections. 

The following range of connection IDs apply to Fixed Asynchronous Connections: 

'20 ? H: Flow Control Connection 

4 21 ' .. 'SO'H Fixed Asynchronous Connections 



Asynchronous Xteta Transmission: Exairple 
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Explanation of Above Diagram 

The above diagram shows a source device sending data to a destination device over a fixed 
asynchronous connection (FC) on HS D2B. 

The 'Empty 1 indicator from the source's (Tx) buffer together with the Flow Control Bit 
determine whether or not padding needs to be inserted into the transmitted FC datastream. 

The 'Full' indicator from the destination's (Rx) buffer is used to determine the state of the 
flow control bit. Note that the 'full' level has to be set to take into account the latency 



Multiple Destinations 

In the case where there are multiple destinations, the flow control outputs are Ored together in 
the same flow control bit. Thus the device whose buffer fills first will set the flow control bit 
to stop. If the application wishes to pause delivery to one particular destination, then the flow 
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control output from that destination should be kept at '0' (continue) so that data can continue 
to be delivered to the other destinations for that connection. 

When the Source Buffer is not empty & the Destination Buffer is not full 

[In the Source] Data is transferred from the Tx Buffer into the bytes allocated to the (fixed 
asynch. connection) FC within the source data field of the HS D2B frame. 
[In the Destination] Data is copied from the bytes allocated to the FC within the source data 
field of the HS D2B frame into the Rx Buffer 

When the Source Buffer is empty & the Destination Buffer is not full 

[In the Source] No Data is transferred from the Tx Buffer, so padding is inserted into the 
bytes allocated to the FC within the source data field of the HS D2B frame. 

[In the Destination] Padding is recognised by the receiver and thus no data is into the Rx 
Buffer 

When the Source Buffer is not empty & the Destination Buffer is nearly full 

[In the Source] Data is transferred from the Tx Buffer into the bytes allocated to the FC 
within the source data field of the HS D2B frame. 

[In the Destination] Data is copied from the bytes allocated to the FC within the source data 
field of the HS D2B frame into the Rx Buffer. When the buffer reaches full (less an amount 
due to the latency), the destination sets the Flow Control bit to ' V (meaning stop). 

When the Source detects that the Flow Control is set to Stop 

[In the Source] No Data is transferred from the Tx Buffer, so padding is inserted into the 
bytes allocated to the FC within the source data field of the HS D2B frame. 

[In the Destination] Padding is recognised by the receiver and thus no data is into the Rx 
Buffer. When the buffer is no longer full, the receiver sets the corresponding Flow Control bit 
to 'O 5 (meaning continue). 

When the Destination Buffer is no longer full 

[In the Destination] The destination sets the Flow Control bit to '0' (meaning stop). 
Whew the Source detects that the Flow Control is set to Continue 

[In the Source] Data is transferred from the Tx Buffer into the bytes allocated to the FC 
within the source data field of the HS D2B frame. 

[In the Destination] Data is copied from the bytes allocated to the FC within the source data 
field of the HS D2B frame into the Rx Buffer 



b low Control Connection: Signalling irom Destination to Source 



Frame 1 



Frame 2 



□ 



Frame 3 



□ 



Flow Control Bit (J means stop sending) 



Flow control connection (I byte per S fixed asynch connections) 
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• 



9.1.1.1 Latency of Flow Control 

Allowance must be made for delay in the effect of the flow control bit, due to the number of 
source data fields of HS D2B frames which are held in buffers around the ring. This means 
that the flow control bit('V means stop, '0' means start/continue) needs to be asserted before 
the receiver buffer is full, taking into account the amount of data which will be received 
before the flow control takes effect. This depends on the number of bytes used per frame (for 
this connection) and on the number of devices with open source data bypasses in the system. 

The total latency (in bytes): L = (number of sources * 2) * number of bytes in FC per frame, 

where FC stands for Fixed Asynch, Connection and the System Master is always counted as a 
source. 

This latency can be measured by the System Master when the system starts up, by counting 
the number of frames which elapse between transmission and reception of the frame 
containing the start of a source data block (indicated by the SDB bit set to 1 in the HS D2B 
frame header). The System Master then marks this number of frames at the end of the source 
data block with the Transition Period flag Tr set to 1. 



10- Pack/Packet/Cell Hierarchy 



The contents of a source data connection, either fixed or variable, are determined by the 
application- The following is a proposal for one possible form of organisation. 



Pack 



Packet J 



Packet P 




: K. e y : Z ... . I n d i c a t c s th a t th e Yl r s t cell o f a packet is'not ne ces s a r fly" the ~fi r"s I cell of an'of 

| a connection block (FCB or VCB) 

; M A packet must contain at ieasl unc cell and may contain a number of cells 

• (given by M -L+ 1 

; P The number of packets in a pack is defined by the applicaiion within the 

■ limits imposed by the Remaining packets field in th $ cell h 5 s d ? r ; up to 256 

\ packets/pack are supported 



Figure 6: raek,Facke* a lid Ceil Hierarchy 



A packet of source data may occupy an integral number of cells. The packets themselves may 
also be part of a pack as shown in the diagram above. The application may define the number 
of packets in a pack as well as the number of cells in a packet (1 or more, subject to the limit 
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imposed by the Remaining Packets field in the cell header), using the fields provided in the 
packet-slot header. 

10.1 Cell Structure 

The cell provides framing to allow a device receiving the data to identify the data and recover 
it correctly- See the diagram above for an illustration of the structure. 

Cell Header 

Start of Packet flag 1 bit 

Start of Pack 1 bit 

Packet Type 3 bits (=01, for packet type 1) 

Remaining Packets & bits 

Number of bytes in Ceil 1 0 bits 

Error Protection (N-K) 8 bits 



Notes 

1. The Stan of Packet flag indicates whether the first data byte of this cell is also the first 
byte of a packet (flag set to 1) or whether it is a continuation of a packet. 

2. The Packet Type identifies the remaining format of the cell. Cell type 0 indicates an , 
unoccupied cell, i.e. no packet data. 

3. Remaining Packets indicates the number of packets remaining within the current pack 
(group of packets) 

4. Number of Bytes in Cell indicates the number of bytes in this cell which contain valid data 

5. The Error Protection field use is currently undefined. 



10.1.1.1 Cell Data 

Data 102 bytes 

The data contained in the cell is unprotected against errors 

10.1.1.2 Alignment of a cell within a Packet 

The start of the packet is indicated by the Start of Packet bit (set to T) in the cell header. 
When this bit is set, the first byte of data following the cell header is also the first byte of the 
packet data (as opposed to being a continuation of a previous packet). When this bit is not set, 
it indicates that the contents of this cell are a continuation of a packet sent in the previous 
cell. 

Amount of a Fixed Connection Block (FCB) occupied by a Cell 

The number of HS frames required for transmission of a cell is a function of the size of the 
cell (108 bytes) and the width of its containing FC in each HS Frame. If the FC is n bytes 
wide then the celi will encompass (108)/n HS frames. Note that this calculation applies only 
to Fixed Connection blocks, since VCB have a reduced capacity during the transition period. 



1 1 . References 



1. D2B Optical Specifications: Common Protocols v2.2 9 April 1997, Communication & 
Control Electronics Ltd.. 
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2. Source Data Connection Protocols; Extensions v<?-7, which defines application level 
protocols: still in preparation. 

3. Search Algorithm for High Speed D2B Byte Allocation, Brian McGovern, l ar August 
1997. 

12. Change History 

Changes since Version 0.4.7 

1 . Frame format changed 

a) removed parity bit at the end of the frame 

b) removed transparent channels (now redundant) 

c) reduced reserved bits from 6 to 2 

d) increase source data field by 1 byte to 1 12 bytes 

e) moved CF field to be adjacent to preamble 

f) corrected frame period to 20.83 microseconds 

2. 4B/5B Table has been modified; 5B values for '0', and £ F ? have been exchanged to 
increase the number of clock transitions when the frame data is zero. 

3. A 5B value from outside the table has been chosen for presenting null data. 
4- Control Frame Arbitration field is expanded to 4 bits 

5, Variable Connections have their own header 

6. Packet Slot is now renamed to Cell and is decoupled from FCB or VCB boundaries 
7- Pack, Packet and Cell Structure passed to application level 

8. Alternatives for Variable Rate Flow Control have now been eliminated. 

9. Error Protection has been added to the Connection Signalling Messages 
Changes since Version 0,4.7a 

1 . Frame structure changed to unify the source data field, and the size of the source data field 
is now increased to 1 1 1 bytes 

2. Description of fixed asynchronous connections has been added together with a simple 
flow control mechanism. 

3. The 108 byte unit carried within VCBs is now called a cell instead of a packet to simplify 
understanding of the pack/packet hierarchy. 

4. Small adjustments to the sharing calculation (weighted method)h 
Changes since Version 0.4.7 

1, Extension of description of alternative sharing method 
2 -_ Further description of the 'Phasing-In' Period. 

3. Access rules for sources which use the Connection Signalling Channel 

4. Added mechanism for flagging master buffer occupancy 
Changes since Version 0.4.6 
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1 . Delay to Transparent Channels is now matched with the delay to data in the source data 
field. 

2. An outline description of a possible alternative capacity sharing algorithm is given, based 
on each source calculating for its own point in the ring. 

Changes since Version 0.4.5 

1. Addition of a Start of HS D2B Block bit in the last byte of the first part of the HS D2B 
frame 

2. ACB has been renamed VCB (variable-rate connection block), and SCB has been renamed 
to FCB (fixed-rate connection block). 

3. A new Source Data Block has been defined, consisting of 108 frames, not aligned with the 
normal (48-frame) HS D2B Block which is used for control frame message transport. 

4. The VCB header has been merged with the Packet Header to reduce overheads 

5. A one-byte wide VCB is now supported 

6. The packet size has been increased to 108 bytes to reduce overheads 

7. The connection signalling message format has changed to include ring positions of source 
and the furthest destination to allow each source to determine which connections overlap 
its own. 

8. The allocation sharing algorithm has been refined to give a less wasteful sharing of surplus 
capacity once the minimum requirements have been met. Each source must also take into 
account the sources which overlap their connection but also the sources whose sources are 
overlapped by these overlapping connection and so on until all relevant sources are 
included in the calculation. 

9. Sources are now responsible for removing ACB s of connections whose furthest destination 
precedes this source in ring position. 

10. Support for S/PDlF's 'VUC and S 5 bits is now provided via the normal source data field, 
i.e. if a connection needs to carry these then it must allocate an extra byte for this purpose. 
The byte will then carry : left VUC (3 bits); right 3 bits); 

Changes since Version 0.4.4 

1 . Alteration of frame structure to accommodate 8-bit frame preamble needed for 4B5B 
Coding. Subframe preambles are no longer used. 

2. The S/PDIF bits (VUC and SB) must now be routed in a normal source data byte instead 
of having reserved bit fields at the end of the frame. 

Changes since Version 0.4.3 

T C~ T*\~*~ "0 „--U - 1 J C £Z 

a. k^vuivc i s la t-n uj iOo o uu"ii cJLi-iaO ii^A^Uki^u to - 

Changes since Version 0.4.2 

Line Coding section added. 
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CLAIMS 

1. A local communication system comprising a ring 
network conveying source data in both variable rate and 
5 fixed rate channels, by means of a regular frame 
structure, each frame providing a fixed number of source 
data fields # wherein each fields can be reserved 
dynamically to form part of a fixed-rate channel using 
the same fields in each frame, and at other times can be 
10 allocated to form part of a variable rate channel for 
irregular data packets . 



2- A system according to claim 1, wherein blocks for 
fixed rate data are allocated starting from one end of 
15 the frame, while fields for variable rate data are 
allocated starting at the other end of the frame. 

3. A system according to claim 1 or 2, wherein 
successive frames are grouped into blocks, and each 
20 variable rate channel occupies the same fields through 
all frames of a block, fields being reallocated to 
provide variation of channel width only at the start of 
each block. 

25 4. A system according to claim 1, 2 or 3, wherein a 
block header is transmitted to reserve a variable rate 
channel of a specified width for a plurality of 
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successive frames. 

5. A system according to claim 4, wherein said block 
header occupies one or more fields of the channel for at 

5 least the first frame of the block. 

6. A system according to claim 4 or 5, wherein at the 
start of a block, each channel's block header occupies 
one or more fields which can be located in the frame with 

10 reference to the widths of other channels • 

7. A system according to any preceding claim, wherein 
each variable rate channel comprises a selection of 
fields fixed over a predetermined sized block of frames, 

15 the width of all such channels being specified in the 
source data fields of the first frame or frames of each 
block . 

8* A local communication system comprising a ring 
20 network conveying source data in both variable rate and 
fixed rate channels, by means of a regular frame 
structure in which certain portions of each frame are 
reserved for said fixed rate channels, whether or not 
o^t^h f i v sd rnt° ch£nr!?ls 5.re in 3 nH certain oth^r 

25 portions of each frame are available for said variable 
rate channels, and a control mechanism is provided for 
allocating said variable rate portion dynamically between 
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different channels . 



9. A system according to claim 1, 2 or 8 , wherein the 
frame rate is synchronised with one or more digital audio 
5 data sources, for which source data is carried in the 
fixed rate portions of each frame. 

10 • A system according to claim 1, 2, 8 or 9, wherein 
each frame conveys control bits forming part of a control 
10 message frame transmitted over plural frames. 

11. A locals communication system, . .comprising _ a 
synchronous ring network conveying source data in a fixed 
rate channel over one segment of the ring and while said 
15 fixed rate channel is multiplexed with variable rate 
channels over another segment of the ring. 



12. A system according to claim 11, wherein said 
multiplexed fixed rate channels and variable rate 
2 0 channels comprise different respective portions within 
a regular frame structure on said other segment of the 
ring . 

12 - J\ fibre optic loc^l comn*ti nidation . svstem - for 
25 example according to any of claims 1 to 12 f suitable for 
in- vehicle entertainment, communication and/or navigation 
purposes, having an overall source data capacity greater 
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5 



10 



15 



than 10 Mbps, the fibre optic channel conveying 4B5B or 

8B10B encoded data- 

14. A system according to any preceding claim, wherein 
variable data source data channels are mapped on to the 
network in asynchronous transfer mode packets. 

15. A fibre optic local' communication system, for 
example according to any of claims 1 to 12 , suitable for 
in-vehicle entertainment, communication and/or navigation 
purposes, having an overall source data capacity greater 
than 10 Mbps, the source data comprising variable data 
rate audio and video data, carried by asynchronous 
transfer mode (ATM) packets. 

16. A system according to claim 15, wherein the headers 
and data fields of ATM packets do not necessarily consist 
of 5 bytes and 46 bytes respectively. 



20 



17. A local communication system substantially 
described herein. 



his Page Blank (uspto) 



